其實導入APS並不但單純導入系統（這是老話，但也像是空話），前面也聊過供應鏈的問題是盤根錯節的，通常看到、感到的問題都只是表徵或是冰山一角。所以藥方也應該是全面性的，才有成效。
前年在一個導入專案時，就看到整個規劃流程因為產品主檔資料、銷售部門的行為以及績效衡量權責不清等等的影響，造成供應鏈運作無效率而且造成庫存很高（他們一開始提到的表徵），且讓我慢慢道來。
電子零件生產、測試後，可能因為品質的等級而分成不同的級別；而不同的客戶可以接受的級別就不同。龜毛的客戶只接受最佳等級的，不龜毛的就什麼都可以。加上產品改版又產生不同版次的產品，客戶也不是什麼版次都接受。簡單的說，要能夠出貨，必須考慮「版別」與「品質等級」兩項因素，如果有3個版別、4個品級，那就是有12種成品的規格。
所以銷售部門就掌握了「配貨」的生殺大權。他們的運作流程是由銷售部門對生管部門提出需求，然後由生管部門進行規劃、交由製造單位進行生產，然後交給銷售部門「配貨」出貨。
對銷售部門而言，他的目標是提高訂單的及時交貨率，所以就會將他們打算出貨的數量整理好，交給生管規劃排產。
而生管的績效指標是：1)產能利用率 2)銷售需求滿足率 3)庫存量。所以生管就將銷售部門所提的需求直接進行排產。假設每生產10個成品大約可以有6個是A級品、3個B級品、1個C級品；但是銷售部門就只給一個數字：100個。對生管部門而言，他就想辦法備100個的料、做出100個成品就好。這樣他的產能利用率達到了、也滿足了銷售需求、而料也只買了100套，沒有多餘庫存。
等到銷售部門要「配貨」時，卻發現只有60個A級品，出不了100個的那張訂單。然後就是急單、趕快備料、趕工...一堆急事。更甚者，那些B級、C級品如果沒有客戶要，那就慢慢的變成呆滯庫存，最後就只能當呆帳打掉。以上還沒講到「版別」，如果加上版別，你可以猜到整個庫存的數量會變得如何的恐怖。
這樣的問題是APS就可以解決的問題？當然不是，自產品開發就開始有問題了：
問：為什麼要換版別？
答：因為BOM表裡面的零件換了
問：為什麼換零件？
答：因為供應商不同，所以同樣的零件料號不同；所以料表就不同了
問：幹嘛供應商不同就要編不同料號？
答：因為公司規定
問：.........
銷售呢？
問：為什麼要配貨？
答：因為客戶能接受的版別、品級不同
問：都只能接受最高品級、最新版別嗎？
答：不一定啊，看客戶
問：那為什麼不先去扣掉現有庫存再把淨需求給生管規劃？
答：庫存是生管單位的責任，他自己要算
問：........
可以看到這些問題都不是APS就能夠解的，而是公司政策、作業流程、衡量指標等等面向相關的，如果單純的以為APS就能全解，那麼一定是太傻、太天真了。
但是一般APS的導入不會先就業務流程面分析、建議改善，而是會直接進入系統功能需求的討論，想辦法把功能做出來。但是可能被其他面向的問題搞到根本無法上線，讓導入團隊與客戶都陷入泥沼之中。
甚至遇到比較「驕傲」的公司，他們會認為自己的流程作法是best practice，根本不需要改，而是要由系統來fit他們。而這些APS都是基於某種預設流程架構所開發出來的，不一定能夠支援這些奇奇怪怪的作業模式，因此最後還是落得失敗收場。
所以真正要做完整、正確的系統導入，還是需要先由使用者提出現有困境、問題為何？如何來衡量這方面的績效？然後透過作業分析，找出所有相關的原因進行改善，這些原因有的甚至是系統導入的前置作業以及必要條件，如果沒有完成，系統也就無法導入運行。在這樣的過程裡，進行前期的工作時必須也要了解未來如何透過系統來輔助進行；而後來的系統建置人員也要了解系統所將扮演的角色與提供的功能。
講起來簡單，但是往往因為時間的壓縮、預算的限制，都是直接進入系統建置，只想求「自動化」，而並不是透過系統「優化」作業。結果反而是專案無法上線、系統效果不佳，更是讓人失望。
站在「解決問題」這個角度看，如果真的要解問題，是沒有辦法偷懶的，省去任何一個步驟都不是做好的。
除了導入的方式以外，執行的「人」更是關鍵所在。
第一，顧問終究是顧問，他們不是真正operate business的人，對於作業面的細節並不會完全瞭解；甚至對於產業的瞭解也不會如使用者們這麼深入。我認為，顧問的價值是將使用者的需求、看法結構化，並透過整合提供一個完整的picture。因為使用者在日常生活作業上都是以功能silo為運作中心，例如前面的例子，銷售人員才不管生管規劃的困難，生管也去了解銷售人員如何配貨。而對於一個好的顧問而言，他必須要能了解整個所有的流程，每一個單位的想法、看法，才有機會設計出好的流程與系統。
第二，不要過於相信「方法論」。業務諮詢顧問公司會將一些工作方法整理為所謂的「方法論」，而認為業務諮詢可以按照這樣的方法論來按表操課。方法論就像是一個指南針，它給你一個方向，但是應該是要了解它的精神，活用它。因為每一個客戶、每一個產業、每一個部門都有其特殊性，是不可能期望一套功夫闖江湖的。通常方法論是講述做好一件事情一個一個的步驟，但是進行步驟一時能不能作一些步驟二、三的工作？到步驟三的時候，是不是會需要回去重複步驟一的工作？這都是有可能的。
第三，跳出框框。業務顧問通常就是談談流程、設計未來該怎麼做，而package顧問整天擔心的是功能能不能符合需求，而常常造成兩造的對立(如果兩部分是分開，由兩個團隊來執行，更是衝突一堆)。我看過三個案例，所謂業務流程改善與系統導入是分開，由不同團隊導入的，其結果都是不如預期的。因為業務顧問就是只看他們所談論的流程，並不去考慮系統如何支援、落實。而系統顧問只看功能能不能做到業務需求，而沒有去challenge流程的合理性。當然，在這三個案例裡，因為業務流程已經被設定，系統商只能概括承受沒有機會去挑戰其合理性。不過我想談的是，這就是業務、系統分開的弊端；如果使用者沒有瞭解兩個之間的關係，而還是分開進行，這樣的問題還會一直下去。
沒有留言:
張貼留言